home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000048_owner-urn-ietf _Fri Jan 31 12:40:04 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  2KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA03895 for urn-ietf-out; Fri, 31 Jan 1997 12:40:04 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA03888 for <urn-ietf@services.bunyip.com>; Fri, 31 Jan 1997 12:40:01 -0500
  3. Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA26437  (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 12:39:59 -0500
  5. Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id LAA16342; Fri, 31 Jan 1997 11:39:38 -0600 (CST)
  6. From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  7. Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id LAA04387; Fri, 31 Jan 1997 11:39:55 -0600 (CST)
  8. Date: Fri, 31 Jan 1997 11:39:55 -0600 (CST)
  9. Message-Id: <199701311739.LAA04387@void.ncsa.uiuc.edu>
  10. To: jayhawk@ds.internic.net
  11. Cc: Daniel LaLiberte <liberte@ncsa.uiuc.edu>,
  12.         "Ron Daniel Jr." <rdaniel@lanl.gov>, omar syed <osyed@lerc.nasa.gov>,
  13.         URL mailing list <ietf-url@imc.org>, urn-ietf@bunyip.com
  14. Subject: Re: [URN] Re: Relative URLs and URNs
  15. In-Reply-To: <32F21E1E.4387@ds.internic.net>
  16. References: <199701310644.XAA03311@acl.lanl.gov>
  17.     <199701311656.KAA03953@void.ncsa.uiuc.edu>
  18.     <32F21E1E.4387@ds.internic.net>
  19. Sender: owner-urn-ietf@services.bunyip.com
  20. Precedence: bulk
  21. Reply-To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  22. Errors-To: owner-urn-ietf@bunyip.com
  23.  
  24. Ryan Moats writes:
  25.  > Just to make everyting clear, if the client does not understand the
  26.  > namespace, should treat the NSS as an opaque string, yes? (At least,
  27.  > I certainly hope so...)
  28.  
  29. Nothing else makes sense.
  30. But maybe such a client should commit suicide. :-)
  31.  
  32. As a general rule, for scalability in a world where clients far
  33. out-number the servers, the clients or servers near the clients should
  34. be doing most of the work.
  35.  
  36. dan